Schema Evolution and the Relational Algebra

In this paper we discuss extensions to the conventional relational algebra to support both aspects of transaction time, evolution of a database’s contents and evolution of a database’s schema. We define a relation’s schema to be the relation’s temporal signature, a function mapping the relation’s attribute names onto their value domains, and class, indicating the extent of support for time. We also introduce commands to change a relation, now defined as a triple consisting of a sequence of classes, a sequence of signatures, and a sequence of states. A semantic type system is required to identify semantically incorrect expressions and to enforce consistency constraints among a relation’s class, signature, and state following update. We show that these extensions are applicable, without change, to historical algebras that support valid time, yielding an algebraic language for the query and update of temporal databases. The additions preserve the useful properties of the conventional algebra. A database’s schema describes the structure of the database; the contents of the database must adhere to that structure [Date 1976, Ullman 1982]. Schema evolution refers to changes to the database’s schema over time. Conventional databases allow only one schema to be in force at a time, requiring restructuring (also termed logical reorganization [Sockut & Goldberg 1979]) when the schema is modified. With the advent of databases storing past states [McKenzie 1986], it becomes desirable to accommodate multiple schemas, each in effect for an interval in the past. Schema versioning refers to retention of past schemas resulting from schema evolution. In an earlier paper [McKenzie & Snodgrass 1987A] we proposed extensions to the conventional relational algebra [Codd 1970] that model the evolution of a database’s contents. We did not, however, consider the evolution of a database’s schema. In this paper, we provide further extensions to the conventional relational algebra that model the evolution of a database’s schema. The extensions that support evolution of a database’s contents are repeated here for completeness and because the extensions supporting schema evolution are best explained in concert with those earlier extensions.